Methods and systems for secure interoperability between medical devices

ABSTRACT

An interface device is configured to provide one or more links to first-party medical devices, each of which communicates using a proprietary protocol. The interface device can translate between the proprietary protocol and a second protocol that is accessible via a second link to the interface device. Details of the second protocol can be provided to third parties for configuring third-party medical devices to connect to the interface device via the second link. Using the second link, one or more third-party medical devices can send information to and/or receive information from the first-party medical devices without the need for the third-party device (or devices) to have any information about the proprietary protocol(s) of the first-party medical device(s). The first-party medical devices can include surgical tools and related support equipment and the third-party medical device can include a control station used to monitor and control the tools and support equipment.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/817,575 filed Feb. 19, 2013 entitled METHODS AND SYSTEMS FOR SECUREINTEROPERABILITY BETWEEN MEDICAL DEVICES is a U.S. National StageApplication, submitted under 35 U.S.C. 371, claiming priority to PCTInternational Application No. PCT/US2010/46460 filed on Aug. 24, 2010entitled METHODS AND SYSTEMS FOR SECURE INTEROPERABILITY BETWEEN MEDICALDEVICES.

BACKGROUND

Processor-based devices continue to proliferate and the medical field isno exception to this ongoing trend. For example, a medical procedure caninvolve use of one or more processor-based medical devices. Thesemedical devices can include, but are not limited to, surgical tools,patient monitoring equipment, and patient support devices. The processorof each device can be used for device control, data collection andexchange, and other tasks.

The medical devices used in the procedure may be provided by a singlemanufacturer or multiple different manufacturers. In either case an enduser of a medical device may have limited options if he or she wishes tointerface the device or device(s) from one manufacturer with a device ordevices of another manufacturer. Particularly, each manufacturer ofmedical devices may use a unique communications protocol for datacollection and exchange. Usually, the details of these protocols areproprietary. To protect their competitive position and to ensurehigh-quality operation, manufactures are understandably reluctant toshare proprietary information with competitors.

SUMMARY

Embodiments of the invention discussed herein may allow a medical devicemanufacturer to meet interoperability needs of end users without theneed to share proprietary information. In one illustrative embodiment,an interface device is configured to provide one or more links tofirst-party medical devices, each of which communicates using aproprietary protocol. The interface device can be configured totranslate between the proprietary protocol and a second protocol that isaccessible via a second link to the interface device. Details of thesecond protocol can be provided to third parties for configuringthird-party medical devices to connect to the interface device via thesecond link. Using the second link, one or more third-party medicaldevices can send information to and/or receive information from thefirst-party medical devices without the need for the third-party device(or devices) to have any information about the proprietary protocol(s)of the first-party medical device(s).

In one embodiment, the first-party medical devices are a plurality ofsurgical tools and related support equipment and the third-party medicaldevice is a control station used to monitor and control the tools andsupport equipment. The tools and support equipment can be connected tothe interface device via respective connections that use a proprietaryphysical communication protocol. For example, in one embodiment thetools use a proprietary serial communication protocol. The interfacedevice can translate between the serial protocol(s) for the first-partydevices and a second protocol that is available to the control stationover an Ethernet connection.

An illustrative method comprises using the interface device to poll afirst medical device over a first interface and to act as a server forclient requests from the third-party device(s) received via a secondlink. For example, the second link may comprise a network connectionsuch as a TCP/IP protocol stack provided over an Ethernet or othernetwork link. The interface device can communicate with each of thefirst-party medical devices via a respective first interface while theinterface device is itself in communication with the third-partydevice(s) via the second interface. The interface device can make datafrom respective first-party medical devices available in response toclient requests made using a network port (such as a TCP/IP port)corresponding to each respective first-party medical device. As anotherexample, the interface device can receive data such as commands andsettings for a particular first-party medical device, with the intendeddevice identified according to the port over which the commands andsettings are provided. In response, the interface device can convert thedata to a corresponding first-party device protocol and transmit thedata via the first interface.

These illustrative embodiments are mentioned not to limit or define thelimits of the present subject matter, but to provide examples to aidunderstanding thereof. Illustrative embodiments are discussed in theDetailed Description, and further description is provided there.Advantages offered by various embodiments may be further understood byexamining this specification and/or by practicing one or moreembodiments of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

A full and enabling disclosure is set forth more particularly in theremainder of the specification. The specification makes reference to thefollowing appended figures.

FIG. 1 is a diagram showing an exemplary group of medical devices.

FIG. 2 is a diagram showing an example of how the first-partymanufacturer can allow its devices to operate with third-party hardwarethrough use of an embodiment of an interface device.

FIG. 3 is a flowchart showing steps of an illustrative method carriedout by an interface device.

FIG. 4 is a data flow diagram showing exchange of data between thefirst-party medical devices, an interface device, and a third-partydevice.

FIGS. 5A-5B are a flowchart illustrating an illustrative processingmethod that can be carried out by an interface device.

DETAILED DESCRIPTION

The disclosure of U.S. patent application Ser. No. 13/817,575 filed Feb.19, 2013 entitled METHODS AND SYSTEMS FOR SECURE INTEROPERABILITYBETWEEN MEDICAL DEVICES is hereby incorporated herein by reference inits entirety.

Reference will now be made in detail to various and alternativeexemplary embodiments and to the accompanying drawings. Each example isprovided by way of explanation, and not as a limitation. It will beapparent to those skilled in the art that modifications and variationscan be made. For instance, features illustrated or described as part ofone embodiment may be used on another embodiment to yield a stillfurther embodiment. Thus, it is intended that this disclosure includesmodifications and variations as come within the scope of the appendedclaims and their equivalents.

In the following detailed description, numerous specific details are setforth to provide a thorough understanding of the claimed subject matter.However, it will be understood by those skilled in the art that claimedsubject matter may be practiced without these specific details. In otherinstances, methods, apparatuses or systems that would be known by one ofordinary skill have not been described in detail so as not to obscurethe claimed subject matter.

FIG. 1 is a diagram showing an exemplary group 100 of medical devices.In this example, a table 102 or other support is provided to receive apatient (not shown) who is to undergo a medical procedure. For example,procedures such as arthroscopy and endoscopy may utilize a number ofmedical devices, though it will be recognized that the present subjectmatter can be used in the context of any type of equipment used in anytype of medical procedure.

In this example, the plurality of devices include an ablation probe 104that is used to apply microwave or other energy to tissue during theprocedure. Ablation probe 104 includes a processor-controlled energysource 106. A shaver handpick 108 along with driver 110 may be used inarthroscopic surgery and other procedures to shave bone or otherstructures, with power and torque provided by driver 110 as directed bya processor or microcontroller in response to user inputs. A camerasystem 112 and camera head 114 may be used along with monitor 116 toview anatomical features of the patient during a procedure. Fluidmanagement system 118 may be used to control the volume of one or morefluids in a surgical cavity during the procedure by use of one or morepumps, valves, and the like directed by operation of a processor ofsystem 118.

Still further equipment (not shown) can be used to monitor the patient'svital signs during the procedure, to provide fluids, ventilation, etc.Some or all of this equipment may be controlled by processors such asmicroprocessors, microcontrollers, and other devices. A medical devicemay feature one or more microprocessors and the device architecture isnot intended to be limiting.

Medical devices 100 may be designed to provide data and/or receivecommands over a data interface. For example, the devices may be providedwith serial or other ports so that the devices can be linked to oneanother and/or a control system 120 to provide data, receive commands,etc. Control system 120 may be configured to provide a user interfacethat can be adapted to control different types of devices. For example,control system 120 may comprise a computer workstation, standalonedevice, or some other type of device that can provide a graphical userinterface and/or touch interface. As another example, control system 120may feature buttons, knobs, sliders, and other mechanical interfacesthat can be mapped to provide devices input along with indicatorslights, dials, light emitting diode (LED) outputs, and the like toprovide device outputs.

As noted above, problems may arise when an end user wishes to usedevices provided by different manufacturers. Particularly, althoughdevices 100 may include serial or other communications ports, devicesfrom one manufacturer may communicate using a proprietary protocol thatis not available to other manufacturers. For example, a manufacturer ofdevices 104, 106, 108, 110, 112, 114, 116, and 118 (the “first-party”manufacturer) may wish to allow its devices to operate with a controlsystem 120 provided by a different manufacturer (a “third-party”manufacturer), but may be unable to share the details of thecommunications protocol(s) used by devices 104-118. In this example, allof devices 104-118 are provided by the same manufacturer. However, asanother example, some of devices 104-118 may be provided by thethird-party manufacturer and may be able to interface directly with thethird-party manufacturer's control system 120. The user may wish to useat least one device provided by the first-party manufacturer, and can doso using interface device 122.

As another example, the first-party manufacturer may actually providedevices provided by another party (a “fourth party”) and the first-partymanufacturer may have access to the control protocol(s) of the fourthparty devices for interoperability purposes. For purposes of theexamples herein the “fourth party” devices can be treated the same asthe first-party devices.

FIG. 2 is a diagram showing an example of how the first-partymanufacturer can allow its devices to operate with third-party hardware.In this example an interface device 122 is provided to provide a bridgebetween devices 104-118 and third-party controller 120. Interface device122 features a plurality of first hardware connection ports 124 whichare configured to connect to corresponding data interfaces of devices106, 110, 112 and 118 over links 126, 128, 130, and 132, respectively.Interface device 122 also features a second hardware connection port 134that provides a link 136 to third-party controller 120. In this example,devices 104, 108, 114, and 116 are linked to respective base units andare not independently linked to interface device 122, but it will beunderstood that the particular group of devices and data flowarrangement amongst the devices is shown for purposes of example only.Embodiments include the use of more or fewer hardware connection ports124 than the number shown in this example.

Interface device 122 comprises a processor 138 and memory 140. Memory140 embodies program instructions 142 that can be carried out byprocessor 138 to translate between one or more protocols used by devices104-118 and a protocol used by device 120. Data 144 is shown torepresent data received from one or more of devices 104-118, datareceived from device 120, working data of interface device 122, and/ordata to be sent to one or more of devices 104-120. Processor 138 cancomprise any suitable processing device or devices including, but notlimited to microprocessors, microcontrollers, and the like.

In one embodiment, processor 138 comprises a multitasking processor thatcan access a first bus 146 to send/receive data via hardware connectionports 124 while a second bus 148 is used to send/receive data viahardware connection port 134. Port 134 may, for example, comprise anRJ45 port, with processor 138 configured to provide an Ethernet (IEEE802.3) network interface, although a coprocessor such as a networkcontroller can be used to manage the network interface in someembodiments. In addition to or instead of an RJ45 port, otherembodiments might utilize any suitable serial or wireless interface.

Each port 124 can be configured to provide a suitable physical link toits corresponding medical device. Although all ports are shown here as“port 124,” it will be understood that the various instances labeled asport 124 could vary in construction (e.g., number and type of physicalconnectors). For instance, depending on the first-party manufacturerand/or the particular devices, ports 124 may comprise serial ports ofthe same or different configuration, such as RS-232 connections, USBconnections, etc. As another example, one or more ports 124 couldcomprise parallel ports, RJ45 or other ports, or any other physicallink. Wireless technology (e.g., IEEE 802.11, 802.16, or another radiotechnology) could be used in providing the physical link to one or moreof ports 124 and/or port 134 as well, provided the wireless technologywas suitable for use in a medical environment. Other examples ofphysical connections that can be used on either or both sides includeEthernet, RS-485, RS-422, and Infrared (IR).

Although not shown here, interface device 122 can include additionalfeatures. For example, if one or more of devices 104-120 is configuredto draw power on its data interface, then the corresponding port(s) ofinterface device 122 can be configured to provide power (e.g., +5V DC ifrequired) from a suitable power supply connected to interface device122. Additionally, although a single port 136 is shown, interface device122 could support multiple physical connections for relaying data andcommands via the second protocol.

In any event, program instructions 142 configure processor 138 tocommunicate with devices 106, 110, 112, and 118 according to theproprietary first-party protocol(s) used over each respective link 126,128, 130, and 132. The first-party protocol(s) can include any number ofcommunications protocols used by the devices. In some cases all devicesmay use the same proprietary protocol. On the other hand, in some casesone or more of devices 106, 110, 112, and 118 may have a device-specificcommunications protocol.

Regardless of the number or type of first-party communication protocols,program instructions 142 can enable processor 138 to send and receivedata and/or commands according to the protocols. Program instructions142 further configure processor 138 to communicate with device 120 usinga second communications protocol, the details of which can be revealedto third parties to allow device 120 to interoperate with devices106-118. Examples of this communication will be discussed below inconjunction with FIGS. 3-5.

FIG. 3 is a flowchart showing steps of an illustrative method 300carried out by an interface device such as device 122. Block 302represents connecting to the first-party device or devices (e.g.,devices 106-118 of FIG. 2), such as verifying the physical connectionand carrying out appropriate handshaking according to the first-partycommunication protocol(s) of the respective first-party device(s). The“first-party devices” can include any medical devices that communicateusing a communications protocol defined by an entity separate from anentity that provides a “third-party device.” Typically, all first-partydevices may originate from the same entity, although it is possible thatthe first-party devices could include devices from manufacturers of agroup that shares a communications protocol in a controlled manner. Asnoted above, the first-party devices may all share a common, butproprietary, protocol or various first-party devices may utilizedistinct first-party protocols.

Block 304 represents connecting to the third-party device or devices(e.g., device 120 of FIG. 2) according to the second communicationsprotocol. In one embodiment, block 304 comprises establishing aclient-server relationship, with the second communications protocolspecifying a set of polling and error-handling rules to ensure that thelink to the third-party device(s) remains viable. The secondcommunications protocol is different from the first-party protocol (orprotocols) and the details of the second communications protocol can bemade available to providers of third-party devices.

While the link to the third-party device remains viable, the interfacedevice can respond to requests made by the third-party device andidentifying particular devices or functions. This is represented in FIG.3 at blocks 306, 308, and 310.

Block 306 represents receiving a request or command referencing aparticular first-party device. For instance, in one embodiment eachfirst-party device or function is assigned a unique TCP/IP port numberand thus can be referenced in terms of the TCP/IP port number used bythe third-party device in providing a request and receiving data.

Block 308 represents communicating with the corresponding first-partydevice(s) using the respective first-party protocol or protocols, suchas by providing a request or command to the corresponding device overthe appropriate first-party interface. Block 308 may further comprisereceiving data from the first-party device(s). Block 310 representsproviding data from the first-party device(s) according to the secondcommunications protocol. For example, data from the first-partydevice(s) may be converted as appropriate and then sent to thethird-party device. The data may comprise a status update, confirmationof a setting change, etc. In some embodiments, data and messages relatedto particular first-party device are relayed by the interface deviceusing a TCP/IP port specifically associated with that first-partydevice.

In some embodiments, the interface device receives a command at block306, converts the command to the appropriate first-party protocol, andthen at block 308 relays the command to the first-party device, whichthen returns data in response. The returned data can then be convertedand sent to the third-party device at block 310. However, as explainedbelow, in some embodiments the interface device operates on an “ask-me”basis and communicates with the first-party and third-party devicesusing parallel processes—the interface device periodically polls thefirst-party device(s) and has cached data ready from each device forwhen a request is received from the third-party device(s).

In addition to or instead of polling the first-party devices, data maybe provided by the first-party devices in “unsolicited updates” to theinterface device. Similarly, in addition to or instead of waiting forrequests from the third-party device, the interface device may provideunsolicited updates to the third-party device in response to receipt ofupdated data from one or more first-party devices.

FIG. 4 is a data flow diagram 400 showing exchange of data between threeof the first-party medical device(s) (106, 110, and 118), the interfacedevice 122, and the third-party device(s) 120. Three first-party devicesare shown here for ease of explanation, though of course the principlesare applicable regardless of the number of devices.

In this example, interface device 122 is providing data to device 106,which is responding. In particular, handshaking data 402 is interleavedwith a command 404 provided by interface device 122 and device 106responds with interleaved handshaking data 402 and response data 406. Ahandshaking routine may be used initially to establish communicationwith each of the first-party devices according to one or morefirst-party protocols. For example, this can comprise verifying thephysical link, authenticating the device 106 as authorized, andotherwise readying a data communications channel according to thefirst-party protocol for each device. Handshaking data 402 can also beinterleaved with commands and responses as shown here so that theintegrity of the communications link is verified. The particularhandshaking and data protocol (i.e., the first-party protocol) will ofcourse depend on the characteristics of the individual devices, and theuse of reference numeral 402 is for purposes of illustration only and isnot intended to imply that all devices use the same handshakingdata/protocol.

Although interface device 122 can poll the first-party devices, thefirst-party devices need not wait for a polling cycle to provideupdates. Instead, as shown at first-party device 110, embodiments cansupport receipt of a datastream comprising unsolicited update data 408(interleaved in this example with handshaking data 402). For example,first-party device 110 may have a status update based on internalconditions of the device and/or an external condition monitored by thedevice. The unsolicited update can be received by interface device 122and used to update current data set 413.

First-party device 118 is shown receiving an interleaved data streamincluding handshaking data 402, a polling request 410, and a command404. This example shows how various combinations of handshaking,polling, and commands can be used as appropriate for the variousfirst-party devices.

Interface device 122 also performs a handshaking routine withthird-party device 120 but according to the second communicationsprotocol. For example, in one embodiment interface device 122establishes a full TCP/IP communication stack as noted above. In thisexample, a dedicated TCP/IP “heartbeat port” is shown, withcommunication verified by messages 412 and 414 between third-partydevice 120 and interface device 122. By ensuring that the communicationlink between devices 120 and 122 is intact, device 122 can provideunsolicited updates to third-party controller 120. Thus, if device dataand/or status changes, the third-party controller 120 can be updatedmore quickly rather than waiting for a polling cycle to complete. As anexample, if one of the first-party devices comprises a camera or othermonitoring tool that encounters an error and drops off fromcommunication, the third-party controller can be immediately updated. Ifcommunication via the heartbeat port cannot be verified, then anappropriate error condition can be indicated at third-party device120—for example, both devices 120 and 122 may attempt to restore theconnection, with device 120 indicating that data is not available untilthe connection is restored.

FIG. 4 shows additional ports using dashed lines, particularly dedicatedports for each of devices 106, 110, and 118. In some embodiments, eachdevice has a corresponding port number which is defined according to thesecond communications protocol. For example, as shown at 416,third-party device 120 may provide a command according to the secondprotocol and using the TCP/IP port corresponding to first-party device106. The command data 419 can be extracted and stored in memory and thenprovided as a command according to the first-party protocol for thecorresponding device. For instance, command data 419 may be translatedto the stream 402-404-402 provided to first-party device 106. Inresponse, data from the 402-406-402 data stream may be used to updatecurrent data 413 and then provided according to the second protocol asshown at 418.

Interface device 122 also provides a TCP/IP port that corresponds tofirst-party device 110. For example, the unsolicited update (shown at402-408-402) can be used by interface device 122 to update current data413. In response to the occurrence of the update, interface device 122can itself provide an unsolicited update to third-party device 120 viathe port for device 110 as shown at 420.

In this example, there is also a port for device 118. For instance,third-party device 120 may provide a command and request for data usingthe port as shown at 422. In response, interface device 122 updatescommand data and issues the 402-410-404 data stream noted above. Forexample, in FIG. 2 a request from device 120 may be a request for datafrom one or more devices and/or may comprise command(s) for the devices,such as a request from device 120 comprising a command to fluidmanagement system 118 to increase or decrease a flow rate. In oneembodiment, device 120 issues the request on the TCP/IP port numberdedicated to fluid management system 118 along with data identifying thecommand according to a published syntax for the second communicationsprotocol. As an example, the command for increasing flow rate maycomprise an ASCII message stating “Flow++”.

In FIG. 2, processor 138 can identify that the command is intended forfluid management system 118 based on the port number of the clientrequest from device 120. Processor 138 can convert the ASCII messageinto a suitable command syntax for fluid management system 118 and relaythe command over link 132 using the specific protocol for fluidmanagement system 118. The next time fluid management system 118 ispolled or provides an unsolicited update according to the first-partyprotocol, the data it provides will reflect its response to the command.

As another example, in some embodiments a device (such as device 112 ofFIG. 2) may be configured to display image data. Device 120 can requestcurrent image data from camera system 112 by providing a request overthe port number for camera system 112 and suitable syntax identifyingthe desired data (e.g., an ASCII message stating “UpdateImage( )”). Inresponse, interface device 122 can relay the command/request over link130, receive the current data, and then provide the current data overlink 136. Additionally or alternatively, camera system 112 (or anotherdevice) may provide current data to interface device 122 in response toperiodic queries or pings provided by interface device 122. The currentdata can be cached in memory 140 of interface device 122 for easy accessby device 120 via 136.

The datastreams between the first-party devices were discussed insequence above, and in some embodiments a sequence of polling orparallel polling could be used. However, embodiments include those inwhich interface device 122 supports multitasking and therefore variouscommunications can occur simultaneously between interface device 122 andthe different first-party devices. Similarly, communications betweeninterface device 122 and third-party device 120 may also occursimultaneously (and at the same time as communications between device122 and the first-party devices).

As an example in FIG. 4, third-party device 120 may receive data asshown at 418 and 420 at the same time via the respective ports. Duringthis time period, communications 412 and 414 may occur via the heartbeatport to ensure a viable connection. Also during this time period,interface device 122 may be providing and/or receiving data unrelated tothe data shown at 418 and 420—for example, while interface deviceprovides data 418 and 420, even newer data may be en route from therespective first-party device that provided the data, and still furthercommands may be provided to other first-party devices via theirrespective connections.

For purposes of clarity, separate datastream components are not shown at416, 418, 420, and 422. It will be understood that, within theindividual ports, suitable handshaking can occur to ensure the viabilityof the port and the integrity of data exchanged according to the secondprotocol.

FIGS. 5A-5B are a flowchart illustrating an illustrative processingmethod 500 that can be carried out by an interface device. Although thegeneral principle was discussed above in conjunction with FIG. 3, FIGS.5A-5B provide a more detailed example that may be used to provide therobust connectivity and updates demanded in many medical contexts. Inthis example, method 500 begins at 502 and includes two parallelbranches 504 (shown in FIG. 5A) and 506 (shown in FIG. 5B). If theprocessor of the interface device can carry out parallel threads, eachbranch may comprise its own thread, or the branches could be implementedusing a multitasking-capable processor. Additionally, the processor mayprovide an instance of branch 504 for each first-party device, with thedifferent instances of branch 504 used for simultaneous connection withthe connected device.

Each instance of branch 504 represents communication with a respectivefirst-party devices. Block 508 represents determining if the first-partydevice is connected. This can comprise determining if a physicalconnection is present based on line voltage levels, impedance, etc. asis known in the art. If the device is connected, then at block 510appropriate handshaking can be performed to establish an initialconnection.

At block 511, the method checks for an update message from the device.If the device has provided an unsolicited update, then the method movesto block 516, which represents updating current data in memory of theinterface device based on data returned from the first-party device andis discussed below. If no data has been received from the device, thenthe method moves to block 512, which represents polling the device bysending a “ping” or other recognizable message to the device accordingto the first-party device protocol.

In one embodiment, each first-party device is polled every 250milliseconds, though of course other time intervals could be used, and anumber of retries may be attempted. Accordingly, FIG. 5A includes aretry block to represent determining whether a retry is needed. If so,then flow returns to block 512. Otherwise, if no retry is needed flowmoves to block 514, which represents determining if there is a devicetimeout or if a device provides an unexpected or unintelligibleresponse. If so, then an appropriate error-handling routine can betriggered—for example, a limited number of retries of the entire pollingsequence may be attempted before an error condition is provided. Flowthen moves to providing the “keep alive” command while branch 504regresses one level to attempt polling again at block 512. In oneembodiment, after four attempts of the polling sequence (with eachattempt exhausting the number of retries and also resulting in atimeout) the method returns to block 510 to attempt to identify thedevice again.

However, if the polled device responds to the polling at block 512(i.e., there is no timeout at block 514), then block 516 is reached.Block 516 represents updating current data in memory of the interfacedevice based on data returned from the first-party device. The interfacedevice is configured to recognize the data format and communicationsprotocol of each first-party device and to store the returned data inmemory. The data may be stored using a format internal to the interfacedevice, in the format as provided according to the first-party protocol,or may be converted and stored according to the second communicationsprotocol. Appropriate error-handling routines can be used to verify theresponse as noted above—for instance, if checksum data or other codingindicates a problem, an error state may be indicated. The “keep alive”request is also provided and then flow returns to blocks 511-512 toagain check for data and poll the device if needed.

In some embodiments, all of the connected first-party devices can beconnected and communicated with according to branch 504. However, inother embodiments, devices can be polled in turn. Additionally, theroutine can include appropriate handling of deviceconnections/disconnections—when a new device is connected, the pollingsequence can begin and when a device is disconnected appropriate stepscan be taken to end the polling process. In practice, the handshakingand keep alive requests can interleave with the status and serviceupdates once a connection has been established.

If a command is to be provided to a first-party device, the command canbe provided when the device is polled or as a separate message to thedevice. This can be carried out because the interface device understandsthe communications protocol of the first-party device. For example,power level commands for a particular device may be specified at aparticular offset in the command message and/or may require a particularbit sequence to trigger the command. When such a command is to beprovided, the interface device can construct the appropriate bitstreamand include the bitstream in an appropriately-timed message.

Method 500 also includes branch 506, which represents maintaining aninterface for communications with a third-party device according to asecond protocol. In contrast to the protocol or protocols of thefirst-party device(s), which are kept proprietary, the second protocolcan be shared with third-party manufacturers. Additionally, the secondprotocol is not device-specific; instead, the second protocol can beused to exchange data for a plurality of different devices (e.g., forall of the first-party devices connected to the interface device).

Block 520 represents determining if a third-party device is connected tothe port(s) that provide communications using the second protocol. Forexample, if a RJ45 connection is to be used, block 520 can representdetermining if a physical connection is present. Block 522 representshandshaking and setting up an appropriate network communications channelover the connection. In some embodiments, this comprises establishing anetwork socket connection, such as a TCP/IP socket connection, alongwith opening TCP/IP ports corresponding to each connected first-partydevice. Blocks 524 and 526 represent determining if an error occursduring/after handshaking process or if there is a timeout. If so, flowreturns to block 522 to attempt handshaking again.

For example, the third-party equipment may be expected to “check in” atleast every 250 milliseconds, though of course a different time intervalcould be specified. Accordingly, in some embodiments the interfacedevice is configured to allocate a network port (e.g., a TCP/IP port) asa “heartbeat” port for use in monitoring a status of the connection tothe third-party device in order to ensure an ongoing connection. Blocks524-526 may occur continuously based on messages exchanged over a“heartbeat” port, and represent more generally determining whether atleast a request over the heartbeat TCP/IP port has been received. If noheartbeat is detected, the interface device can respond to an errorcondition.

If there are no errors/timeouts, the method moves to block 528, whichrepresents determining if a request for data or a command has beenreceived from the third-party device. If a request is received at block528, the method moves to block 530, which represents decoding therequest. The second communications protocol can specify a syntax foraddressing devices and formatting requests for data, device commands,and the like and the interface device can recognize that syntax. Forexample, the request can be made over a particular TCP/IP port numberfor a specific device and can comprise a command and/or a request forone or more data items. Therefore, block 528 is meant to includemonitoring several TCP/IP ports simultaneously. In practice, severalthreads may be maintained, each thread for coordinating requests andresponses over a corresponding TCP/IP port.

Returning to FIG. 5B, a checksum or other error correction routine checkcan be made. In this example, if there is a checksum error then flowreturns to block 522 via the error state to attempt handshaking again.Assuming no checksum error, requests for data and/or commands can beprocessed as shown at block 532. For a request for data item(s) theinterface device stores the command in a queue so that the command isprovided to the device at the next polling interval. The command may bestored using a format internal to the interface device, in the format asprovided according to the second communications protocol, or may beconverted and queued in the first-party protocol. If the requestcomprises a command; the interface device may directly respond byconverting the command for transmission using the first-party protocolshortly after the command is received.

Retuning to block 528, in this example if no request has been received(or if a received request has been processed), the method moves to block534, which represents determining if there is data to provide. As notedabove, in some embodiments the interface device can provide unsolicitedupdates so that the third-party equipment has the most up-to-date data.As an example, the device may use timestamps and/or status bitsassociated with data items received from the first-party equipment todetermine if the data items have been provided to the third partyequipment.

If there is data to provide, the data is accessed at block 536 and thenprovided at block 538 in a format according to the second communicationsprotocol. As noted above, the data may be stored using the original dataformat or may be converted at the time of storage. In any event, theinterface device is capable of converting the data because the interfacedevice understands the first-party communications protocol and theprotocol used for communicating with the third-party device. Forexample, the protocol for a particular device may specify that devicestatus information (e.g., device power level, temperature, etc.) isincluded at a particular offset in a serial data stream using aparticular bit pattern. The interface device can be programmed toidentify the device status information in the serial data sequence,translate the bit pattern, and to store the status information inmemory. When it is time to convert the data, the interface device canconstruct a message according to the syntax of the second communicationsprotocol and then send the message appropriately (e.g., by sending anASCII message over the TCP/IP port corresponding to the device whosestatus is being updated).

The method shown in FIGS. 5A-5B is provided for purposes of illustrationonly. For instance, embodiments may return current data in response toqueries from the third party device. For example, if the request atblock 530 is for current data, then at block 532 the interface devicecan provide a query for updated data item(s) over the first interfaceusing the first-party protocol and, when updated data is returned, thedata can be converted for transmission using the second protocol atblocks 536 and 538.

In practice, the interface device can also carry out suitable routinesto enter and exit the polling and data exchange routines upon error andother events such as device shutdown. Additionally, the interface devicecan support administrative and security processes as well.

In one embodiment, the interface device includes an authenticationroutine for verifying access via the second interface and/or to provideadministrative commands to the interface device. For example, thevarious first-party device ports may be enabled or locked in response toadministrative commands, network options may be set, and deviceparameters may be adjusted. In some embodiments, the administrativeinterface can be used to update the interface device programming tosupport additional first-party devices and/or changes to supportedfirst-party communications protocols.

General Considerations

The use of “adapted to” or “configured to” herein is meant as open andinclusive language that does not foreclose devices adapted to orconfigured to perform additional tasks or steps. Additionally, the useof “based on” is meant to be open and inclusive, in that a process,step, calculation, or other action “based on” one or more recitedconditions or values may, in practice, be based on additional conditionsor values beyond those recited. Headings, lists, and numbering includedherein are for ease of explanation only and are not meant to belimiting.

Embodiments in accordance with aspects of the present subject matter canbe implemented in digital electronic circuitry, in computer hardware,firmware, software, or in combinations of the preceding. In oneembodiment, a computer may comprise a processor or processors. Theprocessor comprises or has access to a computer-readable medium, such asa random access memory (RAM) coupled to the processor. The processorexecutes computer-executable program instructions stored in memory, suchas executing one or more computer programs to interact with first-partyand third-party equipment as noted above.

Such processors may comprise a microprocessor, a digital signalprocessor (DSP), an application-specific integrated circuit (ASIC),field programmable gate arrays (FPGAs), and state machines. Suchprocessors may further comprise programmable electronic devices such asPLCs, programmable interrupt controllers (PICs), programmable logicdevices (PLDs), programmable read-only memories (PROMs), electronicallyprogrammable read-only memories (EPROMs or EEPROMs), or other similardevices.

Such processors may comprise, or may be in communication with, media,for example tangible and non-transitory computer-readable media, thatmay store instructions that, when executed by the processor, can causethe processor to perform the steps described herein as carried out, orassisted, by a processor. Embodiments of computer-readable media maycomprise, but are not limited to, all electronic, optical, magnetic, orother storage devices capable of providing a processor, such as theprocessor in a server, with computer-readable instructions.

Other examples of media comprise, but are not limited to, a floppy disk,CD-ROM, magnetic disk, memory chip, ROM, RAM, ASIC, configuredprocessor, all optical media, all magnetic tape or other magnetic media,or any other medium from which a computer processor can read. Also,various other devices may include computer-readable media, such as arouter, private or public network, or other transmission device. Theprocessor, and the processing, described may be in one or morestructures, and may be dispersed through one or more structures. Theprocessor may comprise code for carrying out one or more of the methods(or parts of methods) described herein.

While the present subject matter has been described in detail withrespect to specific embodiments thereof, it will be appreciated thatthose skilled in the art, upon attaining an understanding of theforegoing may readily produce alterations to, variations of, andequivalents to such embodiments. Accordingly, it should be understoodthat the present disclosure has been presented for purposes of examplerather than limitation, and does not preclude inclusion of suchmodifications, variations and/or additions to the present subject matteras would be readily apparent to one of ordinary skill in the art.

What is claimed is:
 1. An apparatus for providing interoperability amonga plurality of medical devices, the plurality of medical devices eachhaving a corresponding data interface, the apparatus comprising: aplurality of ports, each port being operative to connect to thecorresponding data interface of a respective medical device; at leastone memory; and at least one processor operative to execute at least onecomputer program out of the at least one memory: to receive, from eachof at least some of the plurality of medical devices, informationpertaining to one or more of a data format, a syntax, and one or moresettings employed by the respective medical device, wherein theinformation received from the respective medical device is indicative ofone or more of (1) input data that the respective medical device iscapable of receiving from at least another one of the plurality ofmedical devices, and (2) output data that the respective medical deviceis capable of providing to the other one of the plurality of medicaldevices; and to establish, over the port connected to the correspondingdata interface of the respective medical device, a communication linkbetween the respective medical device and the other one of the pluralityof medical devices using at least some of the information received fromthe respective medical device.
 2. The apparatus of claim 1 wherein theat least one processor is further operative to execute the at least onecomputer program out of the at least one memory to concurrently receivethe output data from the respective medical device and at least theother one of the plurality of medical devices.
 3. The apparatus of claim2 wherein the at least one processor is further operative to execute theat least one computer program out of the at least one memory to storethe output data received from the respective medical device and theother one of the plurality of medical devices in the at least onememory.
 4. The apparatus of claim 3 wherein the at least one processoris further operative to execute the at least one computer program out ofthe at least one memory to provide the output data received from therespective medical device as the input data to the other one of theplurality of medical devices.
 5. The apparatus of claim 4 wherein the atleast one processor is further operative to execute the at least onecomputer program out of the at least one memory to provide the outputdata received from the other one of the plurality of medical devices asthe input data to the respective medical device.
 6. The apparatus ofclaim 5 wherein one or more of concurrently receiving the output data,storing the output data, providing the output data received from therespective medical device, and providing the output data received fromthe other one of the plurality of medical devices are performed based onat least some of the information used to establish the communicationlink between the respective medical device and the other one of theplurality of medical devices.
 7. The apparatus of claim 6 wherein theproviding of the output data received from the respective medical deviceas the input data to the other one of the plurality of medical devicesis further performed without the other one of the plurality of medicaldevices soliciting the output data from the respective medical device.8. The apparatus of claim 6 wherein the providing of the output datareceived from the other one of the plurality of medical devices as theinput data to the respective medical device is performed without theother one of the plurality of medical devices being solicited by therespective medical device to provide the output data.
 9. The apparatusof claim 1 wherein the at least one processor is further operative toexecute the at least one computer program out of the at least one memoryto receive, from each of at least some of the plurality of medicaldevices, further information pertaining to one or more control messagesthat the respective medical device is capable of accepting from theother one of the plurality of medical devices.
 10. A method of providinginteroperability among a plurality of medical devices, the plurality ofmedical devices each having a corresponding data interface, the methodcomprising: receiving, at an apparatus from each of at least some of theplurality of medical devices, information pertaining to one or more of adata format, a syntax, and one or more settings employed by therespective medical device, the information received from the respectivemedical device being indicative of one or more of (1) input data thatthe respective medical device is capable of receiving from at leastanother one of the plurality of medical devices, and (2) output datathat the respective medical device is capable of providing to the otherone of the plurality of medical devices, the apparatus including aplurality of ports, each port being operative to connect to thecorresponding data interface of a respective medical device; andestablishing, over the port connected to the corresponding datainterface of the respective medical device, a communication link betweenthe respective medical device and the other one of the plurality ofmedical devices using at least some of the information received from therespective medical device.
 11. The method of claim 10 furthercomprising: concurrently receiving the output data from the respectivemedical device and at least the other one of the plurality of medicaldevices.
 12. The method of claim 11 further comprising: storing theoutput data received from the respective medical device and the otherone of the plurality of medical devices in the at least one memory. 13.The method of claim 12 further comprising: providing the output datareceived from the respective medical device as the input data to theother one of the plurality of medical devices.
 14. The method of claim13 further comprising: providing the output data received from the otherone of the plurality of medical devices as the input data to therespective medical device.
 15. The method of claim 14 furthercomprising: performing one or more of the concurrently receiving of theoutput data, the storing of the output data, the providing of the outputdata received from the respective medical device, and the providing ofthe output data received from the other one of the plurality of medicaldevices based on at least some of the information used to establish thecommunication link between the respective medical device and the otherone of the plurality of medical devices.
 16. The method of claim 15further comprising: performing the providing of the output data receivedfrom the respective medical device as the input data to the other one ofthe plurality of medical devices without the other one of the pluralityof medical devices soliciting the output data from the respectivemedical device.
 17. The method of claim 16 further comprising:performing the providing of the output data received from the other oneof the plurality of medical devices as the input data to the respectivemedical device without the other one of the plurality of medical devicesbeing solicited by the respective medical device to provide the outputdata.
 18. The method of claim 10 further comprising: receiving, at theapparatus from each of at least some of the plurality of medicaldevices, further information pertaining to one or more control messagesthat the respective medical device is capable of accepting from theother one of the plurality of medical devices.